Summary

This updates the Docker image GitHub Actions workflow to make it more reusable for PR validation, reduce duplication, and add container vulnerability scanning.

It also adds a separate manual release workflow for creating a versioned tag/release and dispatching the Docker publish workflow for that tag.

Changes

• add pull_request trigger for builds targeting main
• refactor duplicated amd64/arm64 jobs into a matrix build
• keep DockerHub push/login disabled for PRs
• keep multi-arch manifest creation only for non-PR builds
• derive image namespace from vars.DOCKERHUB_NAMESPACE || github.repository_owner to work better in forks
• add Grype-based scanning of the base Docker image
• upload SARIF results for non-PR builds
• print SARIF output in PR builds instead of uploading it
• keep existing slim-image flow for per-arch slim images
• add Buildx cache configuration to speed up repeated builds
• add a manual release workflow with explicit VERSION input
• create and push a lightweight tag for the requested version
• create a GitHub release for that tag
• trigger postgresql.yml explicitly via workflow_dispatch

Why

This makes the Docker workflow more useful for contributors and forks by allowing PR builds without requiring push credentials, while still preserving the current main/release publishing flow.

It also adds vulnerability scanning so issues in the base image are detected during CI.

The separate release workflow keeps versioning simple for this repository by requiring an explicit version instead of computing one, and avoids recursive workflow limitations by manually dispatching the Docker workflow after the release tag is created.

Behavior

Pull requests

• build amd64 and arm64 images
• scan the base image with Grype
• do not log in to DockerHub
• do not push images
• do not upload SARIF to GitHub code scanning
• print SARIF output in the workflow logs

Push to main

• build amd64 and arm64 images
• scan the base image with Grype
• push arch-specific images
• create and push multi-arch manifests for develop and develop-slim

Manual release workflow

• accept an explicit VERSION input
• create and push a lightweight git tag
• create a GitHub release for that tag
• trigger postgresql.yml on that tag via workflow_dispatch

Notes

• only the base image is scanned; slim images are not scanned separately
• SARIF upload is skipped for all PRs to avoid permission issues and keep fork behavior predictable
• the release workflow uses an explicit version input instead of calculating the next version

Fixes #3